This invention relates to authenticating client operations in networked computer systems, more specifically to authenticating browser requests in a stateless web environment.
The World Wide Web includes a network of servers on the Internet, each of which is associated with one or more HTML (Hypertext Markup Language) pages. The HTML pages associated with a server provide information and hypertext links to other documents on that and (usually) other servers. Servers communicate with clients by using the Hypertext Transfer Protocol (HTTP). The servers listen for requests from clients for their HTML pages, and are therefore often referred to as xe2x80x9clistenersxe2x80x9d.
Users of the World Wide Web use a client program, referred to as a browser, to request, decode and display information from listeners. When the user of a browser selects a link on an HTML page, the browser that is displaying the page sends a request over the Internet to the listener associated with the Universal Resource Locator (URL) specified in the link. In response to the request, the listener transmits the requested information to the browser that issued the request. The browser receives the information, presents the received information to the user, and awaits the next user request.
Traditionally, the information stored on listeners is in the form of static HTML pages. Static HTML pages are created and stored at the listener prior to a request from a web browser. In response to a request, a static HTML page is merely read from storage and transmitted to the requesting browser. Currently, there is a trend to develop listeners that respond to browser requests by performing dynamic operations. For example, a listener may respond to a request by issuing a query to a database, dynamically constructing a web page containing the results of the query, and transmitting the dynamically constructed HTML page to the requesting browser. To perform dynamic operations, the functionality of the listener must be enhanced or augmented. Various approaches have been developed for extending listeners to support dynamic operations.
Because servers on the Internet can be accessed by a multitude of clients, several protection schemes have been developed to protect against unauthorized access of certain information. One approach used to prevent unauthorized access of certain information is to require clients to provide certain authorization information before they can have access to information on a particular server. This authorization information typically consists of such items as a user""s name and a password, a particular IP address, specific domain name or other information that can identify a particular user and/or machine attempting to access information.
One approach to implementing an authorization mechanism is to associate an authentication process with each server. The authorization process intercepts client requests and determines whether the clients should have access to the information associated with the server. Thus, each time a client attempts to access information on a particular server, the authentication process associated with the server first verifies that the client is authorized to access the information.
This authentication-process-per-server approach works well when the HTML pages associated with the server are the items to be protected. However, in systems that use the server to access and execute computer programs that may be running on different machines than the server, this approach may not provide the requisite flexibility. For example, assume that a banking application and a database application are both accessible by browsers through a particular server. The banking application may require a completely different authentication mechanism than the database application, while other uses of the server may not require any authentication at all.
Based on the foregoing, it is clearly desirable to provide an authentication mechanism to restrict access to resources available through an HTTP server. It is further desirable to provide an authentication mechanism that is flexible enough to support different authentication protocols for applications that may be accessed through the same HTTP server.
The present invention provides a highly scalable, flexible, and extensible mechanism for authenticating a request from a client. In a preferred embodiment, the present invention comprises an authentication engine, an authentication host, and a plurality of providers coupled to the host, each provider implementing a selected authentication scheme. In a preferred embodiment, each of the providers takes the form of a module that can be dynamically linked in at run time, such as a dynamic link library (DLL).
The present invention preferably further comprises a machine independent communication mechanism for enabling the various components to communicate with each other across machine boundaries. With this communication mechanism, the various components of the invention are able to communicate with each other regardless of on which machine each component resides. In a preferred embodiment, the communication mechanism takes the form of an object request broker. Because the various components can reside on different machines, the present invention is said to be distributed. The distributed nature of the present invention makes it highly scalable.
In addition to acting as a communication mechanism, the object request broker also preferably performs a load balancing function. More particularly, the broker coordinates the sending of requests to the authentication engine and the authentication host in such a way that it minimizes potential bottlenecks and maximizes use of available resources. In performing this function, the broker utilizes metadata that is registered for each provider at the time the provider is introduced into the system.
In operation, the authentication engine receives a request having a protect string associated therewith. The protect string specifies, among other things, the authentication scheme or schemes that need to be implemented for that request, and the logical operator or operators (e.g. AND, OR) that are to be applied to the results of those schemes. Upon receiving the request, the authentication engine parses the protect string into one or more provider requests, and sends the requests, via the object request broker, to the authentication host. In response, the host forwards the requests to the appropriate providers for processing. The providers, upon completing their processing, send the results, via the authentication host and the object request broker, back to the authentication engine, which then processes the results according to the logical operator or operators specified in the protect string to determine whether the request has been authenticated.
With the present invention, it is possible to alter system implementation at deployment time. As noted previously, each provider preferably takes the form of a DLL that can be linked into the system at run time. Because the providers are linked in at run time, it is possible, at deployment time, to: (1) replace one provider with another provider; and (2) to add another provider to the system. The architecture of the present invention enables all of this to be done without changing or recompiling any of the other modules (e.g. the authentication engine and the authentication host). To replace/add a provider, all that needs to be done is to update the metadata to reflect the replacement/addition of the providers. In addition, it is possible to change the authentication schemes associated with a particular query. This can be done by simply changing the protect string associated with that query. Again, no recompilation is necessary. These aspects of the invention make it possible to change implementation at deployment time, as opposed to compile time. This in turn makes the present invention highly flexible and extensible.
These and other advantages will become clear as the invention is described in further detail.